49장. ECS 배포 전략 — Rolling · Blue-Green
이 장에서 말하고자 하는 것
새 버전 컨테이너를 띄우는 순간은 운영의 가장 위험한 순간이다.
- 새 버전이 죽어 있다면?
- 사용자 트래픽이 어떻게 영향을 받는가?
- 문제가 보이면 얼마나 빨리 되돌릴 수 있는가?
이 질문에 답하는 게 배포 전략 이다.
ECS는 두 가지 표준 전략을 제공한다.
- Rolling Update
- Blue-Green
1. Rolling Update — 기본 전략
ECS의 기본 배포 방식.
v1 v1 v1 v1 ← 시작
v1 v1 v1 v2 ← Task 한 개씩 교체
v1 v1 v2 v2
v1 v2 v2 v2
v2 v2 v2 v2 ← 완료
- 단순하다
- 추가 인프라 거의 안 든다
- v1과 v2가 동시에 트래픽을 받는 구간이 존재
이 구간이 문제가 될 수 있다.
- DB 스키마 호환성 필요
- API 호환성 필요
2. Rolling 의 두 비율 — Max % · Min %
minimumHealthyPercent : 배포 중 최소 몇 % 살아 있어야 하는가
maximumPercent : 배포 중 최대 몇 %까지 띄울 수 있는가
desiredCount = 4
min 50% / max 200%
→ 최소 2개 살아 있고
→ 최대 8개까지 동시 허용
- min 100% / max 200% → 신버전 4개 띄운 뒤 구버전 4개 빼기 (끊김 없음)
- min 50% / max 100% → 자원 절약 (잠깐 적게 운영)
3. Blue-Green — 안전한 전략
ECS + CodeDeploy 조합으로 쓴다.
[ALB]
├─ TG-blue (v1) ← 현재 100%
└─ TG-green (v2) ← 새 버전 대기
배포 시:
1. Green TG에 v2 띄움
2. 헬스 체크 통과
3. Listener forward를 Green으로 전환
4. 문제 없으면 Blue 정리
5. 문제 있으면 즉시 Blue로 되돌림
- 트래픽 전환이 한순간
- 롤백이 빠르다
- 구버전·신버전 혼재 구간 없음
- 자원이 두 배 필요한 순간이 있음
4. Canary — 일부만 천천히 바꾸기
Blue-Green 위에서 트래픽 비율을 단계적으로 옮긴다.
0% → 10% → 50% → 100%
각 단계 사이에 시간을 두고 지표 (에러율 · 지연) 가 정상인지 본다.
5. 어떤 걸 골라야 하는가
일반 마이크로서비스 → Rolling
중요 비즈니스 흐름 → Blue-Green
민감한 변화 → Canary
처음부터 Blue-Green 안 가도 된다.
Rolling + Circuit Breaker + 빠른 롤백이면 운영 90% 커버.
6. Deployment Circuit Breaker
ECS 배포가 실패하면 자동으로 멈추는 안전망이다.
새 Task가 계속 헬스 체크 실패 → 배포 중단
rollback = true → 이전 버전으로 되돌림
운영에서는 사실상 기본값.
7. 우리 서비스에서
배포 시:
[CI/CD]
↓ 새 이미지 푸시
[ECR]
↓
[ECS Service] ← Rolling 또는 Blue-Green
├─ task v1 ──┐
├─ task v1 │
└─ task v2 ←┘
- 기본: Rolling + Circuit Breaker
- 결제 · 인증: Blue-Green
8. 직접 확인해보기 — CLI
# 새 Task Definition으로 업데이트 (Rolling)
aws ecs update-service \
--cluster my-cluster \
--service orders \
--task-definition orders:7
# 배포 상태
aws ecs describe-services \
--cluster my-cluster \
--services orders \
--query 'services[0].deployments'
# 롤백
aws ecs update-service \
--cluster my-cluster \
--service orders \
--task-definition orders:6
9. 코드로는 이렇게 생겼다 — Terraform
resource "aws_ecs_service" "orders" {
name = "orders"
cluster = aws_ecs_cluster.main.id
task_definition = aws_ecs_task_definition.orders.arn
desired_count = 4
launch_type = "FARGATE"
deployment_minimum_healthy_percent = 100
deployment_maximum_percent = 200
deployment_circuit_breaker {
enable = true
rollback = true
}
network_configuration {
subnets = [aws_subnet.private_a.id, aws_subnet.private_b.id]
security_groups = [aws_security_group.task.id]
}
load_balancer {
target_group_arn = aws_lb_target_group.orders.arn
container_name = "app"
container_port = 8080
}
}
Blue-Green이 필요하면 deployment_controller.type = "CODE_DEPLOY" 로 바꾸고 CodeDeploy를 함께 구성한다.
10. 이렇게 쓰면 망한다 — 안티패턴
안티패턴 1. 호환되지 않는 DB 스키마 변경을 Rolling으로 배포
v1·v2가 동시에 살아 있을 때 한쪽이 깨진다.
스키마는 두 단계로 — 추가 → 코드 반영 → 제거
안티패턴 2. Circuit Breaker 없이 배포
새 Task가 끝없이 죽고 다시 떠서 비용 폭증.
안티패턴 3. 배포만 보고 트래픽 영향은 안 본다
새 버전이 5xx 100% 인데도 ECS는 Task 살아 있다고 본다.
배포 직후 ALB 5xx · 지연 · 에러율을 함께 본다
안티패턴 4. 롤백 절차를 모른다
배포 전에 “이전 리비전” 을 메모해 두는 습관.
11. 한 줄로 정리
Rolling은 단순하고 빠르고, Blue-Green은 안전하다.
둘 다 Circuit Breaker와 명확한 롤백 절차가 받쳐야 운영이 된다.
12. 이 장의 핵심 정리
- Rolling은 ECS 기본 전략이며 min/max %로 속도를 조절한다.
- Blue-Green은 트래픽을 한순간에 전환하고 즉시 롤백할 수 있다.
- Canary는 Blue-Green 위에서 트래픽 비율을 단계적으로 옮긴다.
- DB 스키마 변경은 두 단계로 나눠 호환성을 유지한다.
- Circuit Breaker + rollback은 사실상 기본값이다.
- 롤백은 이전 Task Definition 리비전 지정 한 줄.